2. Developer Information

• 2.1 Minimum API Developer Requirements
• 2.2 Payment Gateway – Operational and Maintenance Hours
• 2.3 Security and Firewall Requirements
• 2.4 Parameterised Data
• 2.5 Role Players
• 2.6 Payment Types

Return to Contents

2.1 Minimum API Developer Requirements

1. For PCI compliance the merchant is not permitted to host their own payment page where credit card details are captured. This must be done using the Vodacom Payment page (hosted in Vodacom's secure PCI environment).
2. Payment page templates (such as Amazon Payments, eWay, PayPoint, PayPal, SagePay, WooCommerce, World Pay etc), are not supported.
3. An application developer utilising the Vodacom Payment Page interface must be able to understand and complete the following development steps (at a minimum):
• Construct an HTML form post that conforms to the requirements outlined in 3.5.Step 4: Creating an HTML Form
• Construct an XML or JSON Transaction object object that conforms to the requirements outlined in 3.2. Step 1: Create Transaction Object
• Encrypt the transaction object (using a standard Blowfish encryption algorithm), and include it in the HTML form payload
  (as defined in 3.4. Step 3: Encrypt the Transaction Object and 4.1 Appendix A: Encryption Algorithms).
  The encryption algorithm can be implemented in a variety of languages that meet your requirements (such as PHP, .NET, Java etc).
• Encrypt various form parameters (using a standard Blowfish encryption algorithm), and compare it with the form and server post-backs from payment gateway
  (to ensure there is no man–in–the–middle attack)
  As outlined in 4.2 Appendix B: Control Key – TransactionCompletedURL and 4.3 Appendix C: ControlKey – TransactionStatusCallbackURL

Return to 2. Developer Information

2.2 Operational and Maintenance Hours

2.2.1 QA Environment

Please note that the payment systems undertake maintenance on their QA environment during the following times (SAST):

• 07h00 – 08h00
• 12h00 – 13h00
• 16h00 – 17h00

2.2.2 PROD Environment

• The PROD environment undertake regular releases for which you will be notified prior to implementations.
  The implementation window for these are usually between 23h00–01h00 (SAST).
  Please send a request to PSP-ServiceRequests@vodacom.co.za to be included in the distribution list for these release notifications.

Return to 2. Developer Information

2.3 Security and Firewall Requirements

• TLS 1.2 is required for all browser access to the hosted pages.
• The Merchant end–points to which payments will respond back to, must be accessible from the PCI Payment Gateway..
  As a consequence firewall rules must be applied to successfully post–back to the Merchant..
  The Merchant end–point must be TLS1.2 compliant and be accessible on the internet..
  Please complete the table below and return it to PSP-ServiceRequests@vodacom.co.za and PSP-OperationsSupport@vodacom.co.za and VFSIntegration@vodacom.co.za in order for the firewall change to be logged..
  Please note that firewall changes at Vodacom require a minimum of 48–hour turn–around time.

Table 5. Payment Gateway White–List Requirement

Environment	Payments Source Host Name	Payments Source I.P. Address
QA	https://qa.vodacompaymentgateway.co.za	41.1.32.181
UAT	https://uat.vodacompaymentgateway.co.za	41.1.32.182
PROD	https://psp.vodacompaymentgateway.co.za	41.1.32.185

2.3.1 Payload Encryption

• All payloads sent to Vodacom Payment Gateway must be encrypted
  (see 4.1 Appendix A: Encryption Algorithms for details)

2.3.2 Control Key

• A Control Key must be used between the merchant and the Vodacom Payment Gateway to detect any tampering with messages exchanged
• see 4.2 Appendix B: Control Key – TransactionCompletedURL and 4.3 Appendix C: ControlKey – TransactionStatusCallbackURL for further details

Return to 2. Developer Information

2.4 Parameterised Data

• It is recommended that all fields in various payloads that are marked with a ^ symbol in this documentation, be stored as a run–time configurable parameter in your development.
• The field–values for these objects are subject to change over time, or across environments. This will prevent you from having to release code with new hard–coded values.

Return to 2. Developer Information

2.5 Role Players

2.5.1 Payment Gateway

• Secure website hosted in Vodacom secure domain that allows customer to pay for the goods purchased from merchant.

2.5.2 Customer

• Defined as a person requesting the payment for goods.

2.5.3 Merchant

• Defined as a business or person that provides the goods to the customer, and the merchant will integrate to the VPG.
• The merchant must meet the conditions listed in the following table.

Table 6. Merchant Prerequisites

Condition Type	Condition Details
Bank Registration	The merchant must have a valid merchant registration for eCommerce transactions with Nedbank (Vodacom Financial Services Acquiring Bank)
Hosted Pages	Hosted pages belong to the Payment Gateway in this instance. For more detail refer to Section 6: Merchant Templates of the Merchant Interface Payments Page specification.
Merchant Configuration	Vodacom Payment Solutions Operations team must configure merchant details on TransSmart. The following information is required: Merchant Number Terminal ID MCC Merchant Entity Name Merchant Aliases Merchant Bank Account Number Merchant Business Address Please send a merchant on–boarding request to VPSonboarding@vodacom.co.za Ensure you request a merchant access form to setup a Payserver technical user required for the integration.

Return to 2. Developer Information

2.6 Payment Types

• The Vodacom Payment Gateway will accept the following payment types as allowable payment options, which must be configured per merchant:
• Mastercard
• Visa
• Masterpass
• Vodapay
• Bank test cards are available on Confluence here.
• Bank test card details are updated each morning. Please note these test cards are shared across merchants and as they are test cards with the bank, no guarantees are made to their available funds or functionality

Continue

• Continue to 3. Implementation

Return

• Return to 2. Developer Information
• Return to 1. Introduction
• Return to Contents